Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-125.txt

Text File | 1994-12-08 | 42.1 KB | 1,170 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 28 Jun 92       Volume 1 : Issue 125

Today's Topics:

    developing FBAs
    SUMMARY: marching ants/vbl task and a followup question
    More MPW Linking Blues
    Zortech C++ & MacApp 3
    New Technology to Support Porting to PowerPC-Based Macintosh
    TimeMgr and Spurious Interrupt
    Sound channel allocation failure
    where to find ASP/AFP *server* docs?
    background application
    Comments please: Entity-relationship diagramming tools
    Source Code Request Summary (thermometer indicators)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Francois Schiettecatte)
Subject: developing FBAs
Organization: Johns Hopkins Univ. Welch Medical Library
Date: Tue, 26 May 1992 13:02:20 GMT




First I would like to thank all who have responded to my call
for help of a crashing FBA (error 28). The problem was due
to a bad use of stack space on my part. This has now been
remedied and the application works like a charm. Below is a
list of things to look out for when developing an FBA.


Some guidelines:

Faceless background apps can
- - call InitGraf
- - do anything a normal app can do, except...

FBAs cannot
- - call InitWindows or InitMenus (or just about any other Init____ call)
- - use any quickdraw routine which draws
- - make any call (other than posting a notification) which might
  display a dialog (this limits their use for sending Apple events)


Background only apps get a default stack size of 8k.  This is also the
default stack size of an application running on a classic QuickDraw
machine.  When on a color QuickDraw ROM, the stack size defaults to 24k.
I suspect that you're application is using too much stack space.

Allocate your large data structures in the heap instead as local variables.



You can also increase the stack space allocated to an application:

    SetApplLimit(ptr(StackPtr - 20000));
    MaxApplZone;
    MoreMasters;
    MoreMasters;
    MoreMasters;

Where the 20000 is the amount of stack space required.  The StackPtr
can be got with the following pascal inline procedure:

    function StackPtr: longInt;
    inline
        $2E8F;


In C, things are slightly different:

    SetApplLimit((Ptr)GetApplLimit() - 24576L));
    MaxApplZone;
    MoreMasters;
    MoreMasters;
    MoreMasters;

This will increase the stack space to 24K.


Also you may want to refer yourself to the 9th issue of Develop
which has a very good article on developing FBAs.


Credits and thanks go to the following people:

Grobbins             Apple
Jim Reekes        Apple
Peter N Lewis        NCRPDA, Curtin University




Francois Schiettecatte
Software Engineer
Welch Medical Library
Johns Hopkins University
Internet: [e-mail]
Phone    : [phone]


---------------------------

From: [e-mail] (Andre "A Mac Plumber" Srinivasan)
Subject: SUMMARY: marching ants/vbl task and a followup question
Date: 26 May 92 13:29:58 GMT
Organization: Acme Plumbing Services And Exploding Cigars


thanks to all that reponded to my question concerning marching ants as
a vbl task.  basically, i shouldn't do this: you're not supposed to
call quickdraw routines at interrupt time since some of the routines
can potentially move memory and leave the heap in an inconsistent
state.

questions 1 and 2 were answered by a number of people.  question 3 was
never addressed.

> 1) when a pulldown menu overlaps the ants, the ants just march right
> over the menu.  it looks like i will have to remove the task when a
> mouse down occurs and then install it again afterward.

from Larry Rosenstein:

The Menu Manager draws directly to the screen under the assumption that nothing
else can draw at the same time.

> 2) nothing selected from the apple menu works while my application is
> in the foreground.  when it is suspended, all of these selections that
> i made are launched.

most people agreed with Phil Shapiro who said it best:

This is most likely being caused by a pending update event for your
application that you're ignoring. If there are any pending update
events for you app, then no background tasking will occur. The DA
launching mechanism depends on background tasking; I've seen this
exact bug in action before.

> 3) when i switch to the finder and then return to my app, the ants
> don't march very fast at all; they crawl very slowly.  if i switch to
> some other app and then return, i don't have this problem.

this question was never answered.  at this point i'm just curious why
this happens.  anyone have any insight?

thanks again.

                                -andre.

- --
Andre Srinivasan  :
734 LRDC          :         This Space For Rent
U. of Pittsburgh  :
[e-mail] :

---------------------------

From: killer@wimpy (karl kowalski)
Subject: More MPW Linking Blues
Organization: The Aerospace Corporation; El Segundo, CA
Date: Fri, 15 May 1992 17:58:07 GMT

Anyone have any comments on MPW's rather amusing behavior?

I've set up a resource file (using ResEdit) that includes a SIZE resource,
'cause my program requires a little more than the default application SIZE
given it as an APPL from MPW. Unfortunately, the final application as
created by MPW only gets the default (384k) application size. When I look
at the resources in the linked app, the SIZE resource does in fact contain
the very size I had hoped would end up in the little box at the bottom of
the Get Info window of the selected application. Anyone have any idea why
MPW blatantly ignores the SIZE resource in the linked-in resource file?

In other news, it seems that although I've requested the C compiler to use
the -mc68881 option when doing its thing, the makefile as created by MPW's
CreateMake interface doesn't include the required Libraries in the Link
statement (i.e., it should have things like CSANELib881.o and Math881.o;
instead, it uses CSANELib.o and Math.o, ditto StdCLib.o; it doesn't think
about including CLib881.o at all). Is it just me, or have I got a bogus
MPW and should be thinking about radical action against Apple (please
excuse the potential extreme tone of the last statement; I live in L.A.,
and lately we're prone to a little extremism)?

Cheers,

Karl G "Killer" Kowalski

[e-mail]
[e-mail] (NeXT mail)

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 28 May 92 01:27:51 GMT
Organization: MacDTS Misfits

In article <[e-mail]>, killer@wimpy (karl kowalski) writes:
>
> Anyone have any comments on MPW's rather amusing behavior?
>
> I've set up a resource file (using ResEdit) that includes a SIZE resource,
> 'cause my program requires a little more than the default application SIZE
> given it as an APPL from MPW. Unfortunately, the final application as
> created by MPW only gets the default (384k) application size. When I look
> at the resources in the linked app, the SIZE resource does in fact contain
> the very size I had hoped would end up in the little box at the bottom of
> the Get Info window of the selected application. Anyone have any idea why
> MPW blatantly ignores the SIZE resource in the linked-in resource file?
>
> In other news, it seems that although I've requested the C compiler to use
> the -mc68881 option when doing its thing, the makefile as created by MPW's
> CreateMake interface doesn't include the required Libraries in the Link
> statement (i.e., it should have things like CSANELib881.o and Math881.o;
> instead, it uses CSANELib.o and Math.o, ditto StdCLib.o; it doesn't think
> about including CLib881.o at all). Is it just me, or have I got a bogus
> MPW and should be thinking about radical action against Apple (please
> excuse the potential extreme tone of the last statement; I live in L.A.,
> and lately we're prone to a little extremism)?

Pardon the delay, I'm running a little late on news.

1) MPW doesn't have anything to do with your app's partition; that's all
   handled by the Process Manager and the Finder.  If you included a
   'SIZE' resource, ID -1, properly laid out, then everything should be
   OK.  If not, it's not MPW's fault, as long as the resource actually
   made it into the resource fork of the linked application.

2) If, when you use "Create Build Commands..." off of the default "Build"
   menu, you check the radio button marked "mc68881", the script will
   insert the correct libraries for the 881 option; I just tried it.
   This is handled by these lines in the CreateMake script:

 If {hardwareFloat} == 1
  Set cFloatLib '{CLibraries}Clib881.o {CLibraries}CSANELib881.o {CLibraries}Math881.o d
   #{CLibraries}Complex881.o'
  Set cplusFloatLib '{CLibraries}Clib881.o {CLibraries}CSANELib881.o {CLibraries}Math881.o d
   {CLibraries}CplusLib881.o #{CLibraries}Complex881.o'
  Set pFloatLib '{PLibraries}SANELib881.o'
 End

    (Replace leading spaces with tabs; the d's near the end are option-d's.

    If your script doesn't contain these lines, it's been modified; you
    should reinstall it off of your original disks.

Hope this helps (TM)

Tim Dierks
MacDTS


---------------------------

From: [e-mail] (E.J. Draper)
Subject: Zortech C++ & MacApp 3
Date: 22 May 1992 20:00:45 GMT
Organization: U.T.M.D. Anderson Cancer Center



 Does anyone have any experience with Zortech C++ and MacApp 3?
 And, if so:
1) Does it significatly reduce build times?
2) Does it a make the build process any more of a hassle? (eg. requires
extensive changes to MABuild )
3) Is the code as good (or hopefully better) than MPW?s?
3) Is it worth the money?

Ed

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 May 92 20:05:54 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (E.J. Draper) writes:
>  Does anyone have any experience with Zortech C++ and MacApp 3?
>  And, if so:
> 1) Does it significatly reduce build times?
> 2) Does it a make the build process any more of a hassle? (eg. requires
> extensive changes to MABuild )
> 3) Is the code as good (or hopefully better) than MPW?s?
> 3) Is it worth the money?

   As I know the current Zortech C++ for MPW does not support MacApp 3.0.
The hooks are in place, but there are still some problems with
PascalObject support and the compiler.

   I did testing with the compiler earlier on my own framework (C++ all
the way), it's certainly faster than MPW C++ with load/dump, however
the speed was slightly faster, not radically faster. Didn't see any
speedup differences in the code produced, either.

   The ultimate question is if it's worth switching to a new compiler,
than using one debugged by Apple frequently :-).
- --
                                              Cheers, Kent

PS: Private comments

---------------------------

From: [e-mail] (joseph.m.orost)
Subject: New Technology to Support Porting to PowerPC-Based Macintosh
Date: 26 May 92 16:23:10 GMT
Organization: Echo Logic

NEWS RELEASE

          ECHO LOGIC(TM), AN AT&T VENTURE, ANNOUNCES COOPERATIVE
         DEVELOPMENT AGREEMENT WITH APPLE TO PROVIDE SOFTWARE
           TRANSLATION TOOLS FOR PowerPC(TM)-BASED MACINTOSH(TM)

     Echo Logic's Innovative FlashPort(TM) Technology Provides Macintosh
 Software Developers with Fast and Accurate Translation of ``Shrink-Wrapped''
                         Macintosh Applications

HOLMDEL, N.J., May 4, 1992...Echo Logic, at AT&T venture, today announced an
agreement with Apple Computer, Inc. to cooperatively develop an innovative
set of porting tools enabling the translation of current binary ``shrink-
wrapped'' Macintosh applications to run on the future PowerPC-based
Macintosh.

Using Echo Logic's toolset called FlashPort, Macintosh software developers
will be able to translate the binary versions of their applications in a
matter of days, dramatically reducing the time required to make their
software available on the PowerPC-based Macintosh platform.

According to Echo Logic President Brad Burnham, ``We are pleased to be
working with Apple to develop a Macintosh version of FlashPort.  This first
use of FlashPort will accelerate the availability of current Macintosh
applications so that the future PowerPC-based Macintosh will have a full
suite of software available at product introduction.''

``Availability of FlashPort will be a boon to Macintosh developers,'' said
Roger Heinen, senior vice president and general manager of Apple's Macintosh
software architecture division.  ``This binary translation tool promises to
let developers quickly and inexpensively bring to market versions of their
applications that take advantage of the PowerPC performance.  Meanwhile,
these developers can focus resources on enriching their applications with
new features that become possible with PowerPC performance.''

Echo Logic's development team capitalized on recent advances in data flow
analysis and compiler technology, to develop a toolset which is automatic
enough to be broadly distributed to software developers.  FlashPort will
require minimal human intervention, and will generate an identical
application for the PowerPC-based Macintosh that is competitive with
hand-ported code in performance and size.

According to Chris Macey, Echo Logic's chief scientist. ``FlashPort can
translate any Macintosh program written in any language, from assembler to
C, so developers can continue to work with their current software
development tools.''

Echo Logic has demonstrated the technology to several developers and plans
to make alpha versions of the toolset available to a limited number of
developers later this year.  FlashPort will be generally available in the
second quarter of 1993.

``Of all the approaches to re-hosting software that have emerged over the
last several years, Echo Logic is the only company that will put a binary
software translation toolset in our hands.  We are very excited about that
because it will make it much easier for us to control the quality of our
product,'' said Nolan Larsen, Director on Macintosh Development, WordPerfect
Corporation.

``We have been following Echo Logic's progress for the last several months
and are impressed with their technology,'' said Yuko Takagi, product manager
for 1-2-3 for Macintosh at Lotus Development Corporation.  ``It is likely
that many application vendors, including Lotus, will be evaluating its
potential for migrating Macintosh applications to the new PowerPC
architecture.''

Echo Logic, based in Holmdel, N.J., was founded in August of 1991.  It is a
development-stage company backed by the AT&T Ventures Corporation.

Contact:

Pam Karmazsin
Echo Logic, Inc.
[phone]

Brian Cohen/Jill Balmuth
Technology Solutions, Inc./PR
[phone]

Nancy Morrison
Apple Computer, Inc.
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 26 May 92 20:13:46 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (joseph.m.orost) writes:

   Using Echo Logic's toolset called FlashPort, Macintosh software developers
   will be able to translate the binary versions of their applications in a
   matter of days, dramatically reducing the time required to make their
   software available on the PowerPC-based Macintosh platform.

I've heard and seen enough of this to be convinced it actually will work
well enough. HOWEVER:

   enough to be broadly distributed to software developers.  FlashPort will
   require minimal human intervention, and will generate an identical
   application for the PowerPC-based Macintosh that is competitive with
   hand-ported code in performance and size.

Well, at least 80-90%, which is good enough. However, it's not a
drag-and-drop translator, you might need a few days of human
intervention. Still nifty and time-saving, though !

   Echo Logic has demonstrated the technology to several developers and plans
   to make alpha versions of the toolset available to a limited number of
   developers later this year.  FlashPort will be generally available in the
   second quarter of 1993.

Only problem is, it only runs on RS/6000 boxes, a $50,000 each...
or you can go to them and get it ported. Wonder how many porting
centres there will be in Sweden ? :-(

- --
h++ - new and improved !

A Bus Station is where buses stop. A Train Station is where
trains stop. On my desk, there is a Work Station.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 27 May 92 00:57:04 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Jon W{tte) writes:
> Only problem is, it only runs on RS/6000 boxes, a $50,000 each...
> or you can go to them and get it ported. Wonder how many porting
> centres there will be in Sweden ? :-(

Would one be enough (Stockholm?), this is actually a serious question
because I could push for more centers worldwide? Actually most of the
evangelistic force behind the PowerPC RISC machine are former Europeans
so we should know about the costs of high end RISC boxes over there.
- --
                                              Cheers, Kent



+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 27 May 92 13:53:26 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Kent Sandvik) writes:

   > Only problem is, it only runs on RS/6000 boxes, a $50,000 each...
   > or you can go to them and get it ported. Wonder how many porting
   > centres there will be in Sweden ? :-(

   Would one be enough (Stockholm?), this is actually a serious question
   because I could push for more centers worldwide? Actually most of the
   evangelistic force behind the PowerPC RISC machine are former Europeans
   so we should know about the costs of high end RISC boxes over there.


Erh... I believe that's the AMERICAN price...

Anyway, I personally don't make business decisions, I just
design and hack (and get paid :-) but since we're located
in Stockholm, that's fine by me :-)

- --
h++ - new and improved !

A Bus Station is where buses stop. A Train Station is where
trains stop. On my desk, there is a Work Station.

---------------------------

From: Steve Kohlmeyer
Subject: TimeMgr and Spurious Interrupt
Date: 19 May 92 18:05:33 GMT
Organization: University of Minnesota

Netters --

   I am using the TimeMgr to periodically read data from my National
Instruments AD board.  Then this data is passed through some routines
to clean it up.  I never call any Toolbox functions from within this
TimeMgr task and I feel certain that none of my routines cause the
MemoryMgr to be activated.  The problem is that ocasionally the program
crashes and leaves me in MacsBug with the following message:
  "Spurious Interrupt or Uninitialized Interrupt Vector at
   00431246 'code 0002 046A' +119E"

First of all, what does this message mean?  Secondly, what is causing
it and how can I avoid it?  I am running system 7 on a IIci, using
Think C 5.

Thanks for the help.

Steve Kohlmeyer
U of MN
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 22 May 92 02:48:04 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, Steve Kohlmeyer writes:
>
> Netters --
>
>    I am using the TimeMgr to periodically read data from my National
> Instruments AD board.  Then this data is passed through some routines
> to clean it up.  I never call any Toolbox functions from within this
> TimeMgr task and I feel certain that none of my routines cause the
> MemoryMgr to be activated.  The problem is that ocasionally the program
> crashes and leaves me in MacsBug with the following message:
>   "Spurious Interrupt or Uninitialized Interrupt Vector at
>    00431246 'code 0002 046A' +119E"
>
> First of all, what does this message mean?  Secondly, what is causing
> it and how can I avoid it?  I am running system 7 on a IIci, using
> Think C 5.

It could mean many differenct things.  One idea that comes to mind is
that you've made a SANE or FPU call at interrupt level.  This can cause
and FPU exception and there isn't an exception vector installed to
handle this, so it's labled "spurious interrupt or uninitialized
interrupt vector" by MacsBug.  TMON on the other hand will provide you
with more information as to what the actual exception was.

With out any further information from you, it's all just a guessing
game at this point.  What was the code you're trying to execute?
What exactly does you're task do?


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Jeff E Mandel)
Date: 27 May 92 20:11:01 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> [e-mail] (Jim Reekes)
writes:
>In article <[e-mail]>, Steve Kohlmeyer writes:
>>
>> Netters --
>>
>>    I am using the TimeMgr to periodically read data from my National
>> Instruments AD board.  Then this data is passed through some routines
>> to clean it up.  I never call any Toolbox functions from within this
>> TimeMgr task and I feel certain that none of my routines cause the
>> MemoryMgr to be activated.  The problem is that ocasionally the program
>> crashes and leaves me in MacsBug with the following message:
>>   "Spurious Interrupt or Uninitialized Interrupt Vector at
>>    00431246 'code 0002 046A' +119E"
>>
>> First of all, what does this message mean?  Secondly, what is causing
>> it and how can I avoid it?  I am running system 7 on a IIci, using
>> Think C 5.
>
>It could mean many differenct things.  One idea that comes to mind is
>that you've made a SANE or FPU call at interrupt level.  This can cause
>and FPU exception and there isn't an exception vector installed to
>handle this, so it's labled "spurious interrupt or uninitialized
>interrupt vector" by MacsBug.  TMON on the other hand will provide you
>with more information as to what the actual exception was.
>
>With out any further information from you, it's all just a guessing
>game at this point.  What was the code you're trying to execute?
>What exactly does you're task do?

This is probably correct; I've encountered this before. Generally, the problem
is that you have code which calls the FPU, an interrupt is asserted, and the
interrupt-level code calls the FPU. This hoses the FPU internal state, and
dispatches you to the error handler. There are a whole bunch of errors which
are grouped together under the heading of System Error 11; figuring out which
one is the problem. To this end, I developed a quick and dirty debugger
extension; the code is appended. By calling the PROC startup, the Exception
Vector table (see MC68020 User's Manual, 2nd Edition, section 6.2 (what, you
don't eep yours handy?)) is patched. I have patched the ones related to the
68881,
and fixed it so it breaks to MacsBug and does an IP on the address that caused
the error.
This address can be found in the StackFrame, as well as the VectorOffset, which
tells you the exact error (I use the term "exact" advisedly).

Incidentally, don't use the Time Manager to drive the sampling from the NB-MIO;
it has a timer which can be programmed to generate an interrupt when it
samples. Most importantly, this timer is never preempted by disk activity,
sound manager, serial lines, page faults, etc. As long as you service the
interrupt before the next sample is obtained, your sampling rate stays
rock-steady.

Good luck,


Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]

- --------------------------------------------------------------------------------
- --------
    Machine        MC68020  ; kind of dates the code, doesn't it?
    MC68881

    PRINT        OFF
    INCLUDE    'Traps.a'
    INCLUDE    'ToolEqu.a'
    INCLUDE    'QuickEqu.a'
    INCLUDE    'SysEqu.a'
    INCLUDE    'SysErr.a'
    LOAD    'FlowCtlMacs.d'
    PRINT    ON

*  The stackframe for the routine.

StackFrame    RECORD    0
StatusReg    DS.W    1
ProgCounter    DS.L    1
VectorOffsetDS.W    1
Instruction    DS.L    1
InternalRegsDS.L    2
    ENDR


disaster    PROC    Export

    With    StackFrame

    MOVE.L    Instruction(SP),A0
    MOVE.W    VectorOffset(SP),D1
    AND.W    #$FFF,D1
    Switch# D1
    Case#.S    $0C0
        PEA        #'Branch Error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $0C4
        PEA        #'Inexact result Error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $0C8
        PEA        #'Divide by zero Error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $0CC
        PEA        #'Underflow Error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $0D0
        PEA        #'Operand Error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $0D4
        PEA        #'Overflow Error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $0D8
        PEA        #'Not a number;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $034
        PEA        #'Coprocessor protocol error;IP A0'
        _DebugStr
        Leave#.S
    Case#.S    $038
        PEA        #'Format error;IP A0'
        _DebugStr
        Leave#.S
    Default#.S
        PEA        #'No Idea;IP A0'
        _DebugStr
    EndS#

    RTE
    End

StartUp    PROC    EXPORT
    MOVE.L    A0,-(SP)

*  Patch the low memory interrupt dispatch table so 68881 coprocessor
exceptions
*  give us meaningful messages

    LEA        disaster,A0
    MOVE.L    A0,$0C0
    MOVE.L    A0,$0C4
    MOVE.L    A0,$0C8
    MOVE.L    A0,$0CC
    MOVE.L    A0,$0D0
    MOVE.L    A0,$0D4
    MOVE.L    A0,$0D8
    MOVE.L    A0,$034
    MOVE.L    A0,$038

    MOVE.L    (SP)+,A0
    RTS

    ENDP
    END

---------------------------

From: [e-mail] (Ross Porter)
Subject: Sound channel allocation failure
Date: 22 May 92 16:41:01 GMT
Organization: University of Pennsylvania


I have a piece of code that allocates and uses all four channels
that works just fine on the IIci. However when the same piece of
code is run on an SE/30 or an LC only three of the channels are
allocated and used. The fourth channel allocation call returns
NIL.

Any ideas?  Thanks in advance.

Ross


+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 22 May 1992 18:34:13 GMT

[e-mail] (Ross Porter) writes:
>
>I have a piece of code that allocates and uses all four channels
>that works just fine on the IIci. However when the same piece of
>code is run on an SE/30 or an LC only three of the channels are
>allocated and used. The fourth channel allocation call returns
>NIL.

If these channels are of type sampledSnyth, that's because the Sound
Manager takes quite a bit of CPU time for each channel, and won't
allocate more channels than the CPU can handle.  A IIci can do four mono
channels and the LC only three because of the speed difference.

If they're type waveTableSynth (which "all four channels" would imply),
I've never encountered this problem, but I remember someone else
mentioning something about not getting the fourth channel allocated.
(Paul Potts?  Toby Smith maybe?  Whoever you are, did you fix it?  :-)
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Also thanks to:  Inside Macintosh (except vol. V, ch. 27)"
   - the Tesserae "About..." box

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 25 May 92 20:30:29 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Ross Porter) writes:
>
>
> I have a piece of code that allocates and uses all four channels
> that works just fine on the IIci. However when the same piece of
> code is run on an SE/30 or an LC only three of the channels are
> allocated and used. The fourth channel allocation call returns
> NIL.

If you check the error being returned by _SndNewChannel you should
find that it's giving you notEnoughHardware errors.  This is because
the CPU loading factor for the extra channel was to great of a load
and the Sound Manager will not allow another channel to be allocated.
It all depends on the CPU performance capibilities of the machine you
are running.

You can reduce the amount of CPU bandwidth required for a channel
by turning off linear interpolation.  Set the initNoInterp bit of the
initOptions field when calling SndNewChannel.  This may allow you to
allocate an additional channel on the machine since without interpolating
you'll have more CPU time left over.


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."



+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Tue, 26 May 92 18:43:00 GMT

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>[e-mail] (Ross Porter) writes:
>>

<Jamie McCarthy's lucid comments omitted)

>
>If they're type waveTableSynth (which "all four channels" would imply),
>I've never encountered this problem, but I remember someone else
>mentioning something about not getting the fourth channel allocated.
>(Paul Potts?  Toby Smith maybe?  Whoever you are, did you fix it?  :-)

Nope. It seemed to vary from machine to machine. Some of our IIci machines
simply wouldn't allocate four channels. It's possible another application
was stealing a channel.


- --
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 27 May 92 12:50:55 GMT
Organization: The World Public Access UNIX, Brookline, MA

What error is being returned? If it is a notEnoughHardware error it may
have to do ith CPU load more than anything.






- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm   CI$: 70712,515
- -- communications.networks.cool tunes...

---------------------------

From: [e-mail] (Roy Wood)
Subject: where to find ASP/AFP *server* docs?
Date: 23 May 92 14:00:39 GMT
Organization: International Shared Information Service (Ottawa)

I'm looking for documentation on the *server* side protocols for the ASP/AFP
package (AppleTalk Session Protocol/AppleTalk Filing Protocol).  Inside Mac
volume V describes the workstation side interface, and alludes that the
server side exists, but doesn't say any more than that!  I haven't noticed
anything available from APDA (save a package for writing Unix servers to
interface with ASP/AFP!), or from the ftp-able files on ftp.apple.com.

Would someone please tell me what manual to RTFM?  Help!

- -Roy Wood

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 24 May 92 18:34:19 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Roy Wood) writes:
> I'm looking for documentation on the *server* side protocols for the ASP/AFP
> package (AppleTalk Session Protocol/AppleTalk Filing Protocol).  Inside Mac
> volume V describes the workstation side interface, and alludes that the
> server side exists, but doesn't say any more than that!  I haven't noticed
> anything available from APDA (save a package for writing Unix servers to
> interface with ASP/AFP!), or from the ftp-able files on ftp.apple.com.
>
> Would someone please tell me what manual to RTFM?  Help!

Sorry, there isn't one.  The closest they come is in Inside AppleTalk.

If you want to use these protocols on the server side you'll have
to roll your own.

I doubt you'll see anything over time either.  ASP has some
problems (throughput isn't very good) and Apple is using ADSP
new things.  I'd evaluate using ADSP before you take the plunge
of figuring out ASP!

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --  Makers of...        --   San Jose, California USA 95117
- --                      --   voice: [phone] fax: [phone]
- --     SMOOTHIE         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Richard Harms)
Date: 27 May 92 04:55:47 GMT
Organization: Des Moines, Iowa, Public Access Unix; 515/277-6753

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Roy Wood) writes:
>> I'm looking for documentation on the *server* side protocols for the ASP/AFP
>> package (AppleTalk Session Protocol/AppleTalk Filing Protocol).  Inside Mac
>> volume V describes the workstation side interface, and alludes that the
>> server side exists, but doesn't say any more than that!  I haven't noticed
>> anything available from APDA (save a package for writing Unix servers to
>> interface with ASP/AFP!), or from the ftp-able files on ftp.apple.com.
>>
>> Would someone please tell me what manual to RTFM?  Help!
>
>Sorry, there isn't one.  The closest they come is in Inside AppleTalk.
>
>If you want to use these protocols on the server side you'll have
>to roll your own.

You might take a brief look at CAP available from ftp.rutgers.edu(?)... its
a unix implementation of a number of AppleTalk things, including an
AppleShare server (aufs).

- -rh

- --
Richard R. Harms            Internet: [e-mail]
1217 24th, Suite 49             UUCP: {...}!{rutgers!bobsbox}!grayhawk!rich
Des Moines, Iowa 50311       AOnline: Grayhawk             AppleLink: D2656
                                 Fax: [phone]       Unix: 515/277-6753

---------------------------

From: [e-mail] (Francois Schiettecatte)
Subject: background application
Organization: Johns Hopkins Univ. Welch Medical Library
Date: Fri, 22 May 1992 21:49:14 GMT

I am currently writting a faceless background application and I am
having problems with it. When I set it up so that it runs in the
forground so that I can see debug output in a window it works fine,
but when I remove all the code (using compiler defines) and set the
background only bit on, it crashes with a error 28. The crash
happens always in the same spot. This application requires about
200k of memory to run (that leave me plenty of memory to use in
for variables and stuff like that). Is there something obvious
that I have missed.

A bit more on the application, it sits in the background and listens
out to apple events and responds to them, it launches fine and will
respond to a few event before crashing (when in background mode).

Could it be something to do with the SIZE resource?

francois



+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 25 May 92 20:33:19 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Francois Schiettecatte) writes:
>
> I am currently writting a faceless background application and I am
> having problems with it. When I set it up so that it runs in the
> forground so that I can see debug output in a window it works fine,
> but when I remove all the code (using compiler defines) and set the
> background only bit on, it crashes with a error 28. The crash
> happens always in the same spot. This application requires about
> 200k of memory to run (that leave me plenty of memory to use in
> for variables and stuff like that). Is there something obvious
> that I have missed.
>
> A bit more on the application, it sits in the background and listens
> out to apple events and responds to them, it launches fine and will
> respond to a few event before crashing (when in background mode).
>
> Could it be something to do with the SIZE resource?
>
> francois

Background only apps get a default stack size of 8k.  This is also the
default stack size of an application running on a classic QuickDraw
machine.  When on a color QuickDraw ROM, the stack size defaults to 24k.
I suspect that you're application is using too much stack space.

Allocate your large data structures in the heap instead as local variables.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."



+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 26 May 92 19:55:35 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jim Reekes) writes:
>
> In article <[e-mail]>, [e-mail] (Francois Schiettecatte) writes:
> >
> > I am currently writting a faceless background application and I am
> > having problems with it. When I set it up so that it runs in the
> > forground so that I can see debug output in a window it works fine,
> > but when I remove all the code (using compiler defines) and set the
> > background only bit on, it crashes with a error 28. The crash
> > happens always in the same spot. This application requires about
> > 200k of memory to run (that leave me plenty of memory to use in
> > for variables and stuff like that). Is there something obvious
> > that I have missed.
> >
> > A bit more on the application, it sits in the background and listens
> > out to apple events and responds to them, it launches fine and will
> > respond to a few event before crashing (when in background mode).
> >
> > Could it be something to do with the SIZE resource?
> >
> > francois
>
> Background only apps get a default stack size of 8k.  This is also the
> default stack size of an application running on a classic QuickDraw
> machine.  When on a color QuickDraw ROM, the stack size defaults to 24k.
> I suspect that you're application is using too much stack space.
>
> Allocate your large data structures in the heap instead as local variables.


Corrrection... This time with feeling...

The default stack size for background-only or faceless tasks is NOT 8k.
The default stack size is 0x800 bytes, or 2k.  Sorry for the confusion.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."



---------------------------

From: [e-mail] (Dan L. Cummings)
Subject: Comments please: Entity-relationship diagramming tools
Date: 27 May 92 02:54:11 GMT
Organization: Amoco Production Company, Tulsa Research

I would like to hear your opinions on Entity-relationship
diagramming tools or on more elaborate CASE tools that include
ER capability.

I would prefer something that runs on the Mac, but I can also consider
Unix if the tool uses X-windows.

Thanks in advance,
Dan    <<<< [e-mail]
Path: zslg01
From: [e-mail] (Steve Garwood)

From: [e-mail] (Joseph L. Burnham)
Path: zjlb0a

---------------------------

From: [e-mail] (Sho Kuwamoto)
Subject: Source Code Request Summary (thermometer indicators)
Date: 27 May 92 02:04:51 GMT
Organization: Purdue Univ. Physics Dept, W.Lafayette, IN

Ok.  I dug around in the Finder to get the sizes and colors
used for the thermometer bar, and wrote a THINK C class that
handles thermometer dialog boxes.  If anyone is interested,
mail me and I'll send you the code.

So, is there a central depository for TCL classes?

- -Sho
- --
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Vince Hickey)
Date: 27 May 92 16:24:11 GMT


  I would love to see the source code for the thermometer indicators.  Could
you BinHex it and mail it to me.
Thanks in advance.

Vince

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 28 May 92 01:05:03 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Sho
Kuwamoto) writes:
>
> Ok.  I dug around in the Finder to get the sizes and colors
> used for the thermometer bar, and wrote a THINK C class that
> handles thermometer dialog boxes.  If anyone is interested,
> mail me and I'll send you the code.
>
> So, is there a central depository for TCL classes?

Yes, ftp.brown.edu.
- --
                                              Cheers, Kent



---------------------------

End of C.S.M.P. Digest
**********************